万字长解低代码：三年之内，70%企业将实现技术自由？

点击上图，查看往期高赞文章合集

5月23日我与宝洁大中华区CIO 本家沈锋一起做了一场低代码的直播，分享了实践过程中发现的低代码附带的很多周边效应。

和沈锋总的交流中我了解到，宝洁作为一个大型跨国企业，无论是美国本土，还是大中华区，也都在积极拥抱低代码平台，利用低代码平台来为企业的数字化经营带来帮助。直播的反响不错，把直播里的一些内容在这里做一个汇总和分享。

本文全文10483字，第一部分为关于低代码的十个常见问题，属于低代码入门级解说/解惑，看完基本就明白了低代码是什么、有什么用、跟我如何相关；第二部分为构建一个低代码平台（零售企业适用）需要思考的问题，以及一个低代码平台是如何被构建出来的。

乍眼看上去，这篇文章似乎是程序员才会看的“枯燥”内容，但其实你会发现，构建低代码的过程其实就是一个拆解企业的现场，从业务流程到业务结果——每一个细节都重新认识一遍，用程序员思考的方式重新了解你的企业，或许会发现以往没有注意到的盲点，还会找到新的业务切入点。

图源：艾瑞《2021年低代码行业研究报告》 

01

低代码十问：关于低代码的一切

关于低代码的一些基本问题，我就直播内容汇总了十个问题，希望能够答疑解惑，帮助大家拨开迷雾，少走弯路少踩坑。

1）低代码就是效率提升么？

低代码在效率之外其实还能带来很多额外价值。

我们知道，低代码可以成倍的提升开发效率，除了成本的节省之外，还有很多从量变到质变的效果。以IT满意度而言，原来企业的资源、费用有限，很多小型的，相对低价值的功能实际上是没有精力去帮助业务部门实现的，而这些功能往往非常琐碎而且个性化程度很高，在市场进行招标也很难，通过低代码平台，可以用合理的成本和很高的效率帮助业务部门进行开发，结果就是大大提升了业务部门的满意度。

联通集成做过一个统计，对于某个时间段个性化需求的比例大概如下：页面65%，接口70%，规则82%，这些如果通过低码完成，和传统开发相比，大约可以提升三倍的效率。目前很多低代码平台已经开始尝试与UED进行集成，也就是说，产品经理做的UI设计可以直接构建低代码的界面，进一步提升了研发效率。

我们知道，一个老系统什么时候会被淘汰，往往就是一个字“慢“，慢包含两个维度，一是需求开发慢，二是运行的慢，低代码的高效率带来了高满意度。

2）数字化转型与低代码的关系是什么？

数字化与信息化的区别在于数字化要求将尽可能多的业务都进行数字化，而信息化往往只关注核心业务，这是一个面与点的关系，低代码可以用很低的成本帮助企业将各种犄角旮旯的需求都快速的“业务数据化“，从而为未来的”数据业务化“打下良好的基础。

3）低代码给业务带来什么价值？

低代码可以帮助筛选有价值的业务。

IT经常收到的抱怨和被甩锅的理由有一条：“无法支持业务的创新”。IT同学们往往很委屈，毕竟，根据软件工程学和CMM的定义，如果你的需求都是模糊不清需要摸着石头过河的，怎么可能帮你开发一套完善的软件呢？低代码和无代码工具，可以快速帮业务搭建流程与表单，打通其他业务模块，复用企业已有能力，从而支持新业务的拓展。

有经验的IT同学其实都知道，业务部门提出的需求，70%左右都是无效的，这并不是贬低业务，因为这就是创新的成本，但是通过低代码和无代码平台，可以配合业务以非常低的成本（仅比Excel略高）去尝试新的业务，大浪淘沙，最后剩下的30%真正有价值的功能，我们无论是进行重构还是去采购专业软件，沉没成本都非常低，真正的让IT的资源集中在“有价值的业务”上。

4）除了效率，还能带来些什么？

低代码会带来很多隐性的成本节省。

企业IT构建时，集成成本是一个隐形的成本。例如我们采购了一套软件，它必须和员工、门店、品类、权限等等打通，一般而言对于这些专门定制的集成开发，软件开发商的成本是很高的，码代码和调试接口哪有卖光盘来的挣钱啊，码农的成本那么高。

因此根据我们的估算，大约企业付出的软件采购成本中，15~20%实际上是为了集成买单。如果企业采购了5个供应商的小型应用，实际上每家都需要重复的进行“集成”开发；而采用低代码平台，则可以说是一次集成，日后通用，这里节省下来的成本，积少成多，非常可观。同时，运维也变得更简单，更高效。

5） 大型企业选择低代码的主要原因是什么？

对于大型企业，选择甚至自研自建低代码平台有一个重要的原因就是资产的沉淀。

随着SaaS服务的兴起，很多软件都变成了按年收费，每次升级新的软件和系统又面临大量的集成开发，很多甲方的大型企业发现，低代码是一个很好的沉淀体系，让软件资产、业务经验能够得以沉淀。大型企业自己研发低代码平台成本约为30人，1.5年时间，对于很多超大型企业，这部分自研投资的回报非常高。

图源：艾瑞《2021年低代码行业研究报告》 

6） “复用”这件事真的存在么？

随着中台的兴起与大量的失败，我有一个在头部中台企业担任高管的朋友，曾经很伤心地说，复用是不是个伪命题？而我把低代码看成中台的一种，即逻辑中台，是原来中台体系中缺失的一环，一旦把它补齐，中台的复用价值才会变得完整。

为什么称之为逻辑中台，因为低代码实现了企业业务和运营流程，同时又使得这部分能够被透明的管理。例如，总部指定了主框架，各个区域还可以根据本地的实际情况进行调整，这些调整是透明的，可被监控的，既满足了灵活性，又满足了规范性。

在这里刚好插一句我的观点：企业的中台应该有四种：

a.数据中台：这可以是最早上的，首先可以方便的进行数据清洗，同时企业的数据也可以有一个统一的标准，同时通过微服务架构解决数据展示的性能的问题；

b.业务中台：这是最值得梳理的部分，目的是让企业对自己的业务有微观——宏观的整体认知，同时也是“复用”的基础。

c.逻辑中台：低代码平台，是真正快速将业务中台构建成可落地执行的业务功能的不可或缺的一部分，灵活性和高效率才能放大业务中台梳理以后带来的应用价值；

d.算法中台：这是企业核心资产，是在数据中台基础上沉淀、积累下来的重要数字资产，算法帮助企业提升业务效率，体现差异化。

7）低代码和无代码适合什么样的公司？

效率的提升来自于精细化，开发提效的本质是“开发人员分层”，数字化的推动力来源于算力的上升，算力使得精细化成为可能。

目前看来，大企业有一定的研发人员存在，可以使用低代码，从而提高效率，沉淀资产；小型企业使用无代码，具备Excel中级应用的能力就可以进行开发。目前低代码平台有一个“引擎化”的趋势，大致可分为表单引擎、报表引擎、移动端引擎、流程引擎、集成引擎、规则引擎等，最大的好处是可以边界清晰的分步替换系统，对于大型企业的复杂系统，这一点很重要。

图源：爱分析《2022爱分析·低代码厂商全景报告》 ，低代码应用场景

8）目前低代码平台还有些什么问题？

目前低代码的最大问题是缺乏标准，因此大家不敢使用，因此希望大家一起参与，推动两项重要的执行标准：

a.性能标准，让CIO们清楚的知道，这个平台可以处理多大的业务量，从而与低代码的实施成本进行平衡，帮助选择；

b.兼容标准，如果没有这个标准，那么企业使用了一段时间低代码或无代码平台后，一旦乙方公司出现经营问题，很可能前面的所有开发投入要花相当多的成本才能迁移到另一个平台上，这也是阻碍低代码和无代码发展的一个重要因素。

目前信通院正在推进这个标准，也欢迎大家加入到这个队伍中来，一起把蛋糕做大。低代码不适合做核心算法等计算密集型功能，更适合做业务和逻辑层面的实现；

9）怎样用好低代码、无代码平台？

最好的方式是自研体系+外包团队+低码平台。这样效率最高，研发可控，外包团队可以有效改善需求高峰的拥挤，低码平台降低了对外包人员的要求，同时统一了标准，减少人为的失误。另外，对于一些大型的老牌企业，往往都沉淀了一堆有行业经验，懂开发逻辑的老技术人员，但是他们又很难学会新的开发语言，这时候低代码和无代码可以给予他们第二春，让他们利用丰富的行业经验继续为企业发展提供持续助力。

我们在看低代码提效这件事上，一定不要仅仅关注开发效率的提升，尽可能从应用角度来计算价值，开发效率是单一部门的事，而整体应用价值是全公司的事，清晰的应用价值是帮助我们在公司层面获得资源来推动低代码的重要焦点。

10）这么多厂商，怎么选择？

这也是最常被问到的问题，现在的一线低代码企业和行业平均水平间的技术差距不超过8个月，因此技术问题反而是小问题，要注意的有这几点：

a.选择财务状况好的平台，风险小很多；

b.选择本地企业，最好是本市，其次是本省，因为疫情封控的影响非常大，上线前期遇到疫情封控往往就是一场灾难；

c.选择愿意拥抱标准的企业，降低未来的风险;

d.生态，目前已经有很多企业建设了1500人以上社群，社群是低代码发展的最持续推动力。

趋势表明，到2025年，70%的应用会由低码及无码平台构建，如果我们畅想一下，未来的软件开发可能会是一种什么形式呢？

l 低代码沉淀后，会越来越趋于无代码，无代码下一个阶段则是拼搭型系统，未来的企业软件开发是否会变成像团购接龙一样，某个部门提出一个功能，放置一个入口，其他业务部门在下面接龙，接龙完毕，功能就开发完毕，一个创新业务就可以落地测试了。

l 未来业务部门开会不再需要Excel和PowerPoint，大家直接把软件投影到大屏幕，针对精细化的各类业务处理，讨论完毕直接配置，会议开完，功能就迭代完了。

图源：艾瑞《2021年低代码行业研究报告》 

02

如何做一套适合零售企业的低代码平台 

直播中，和观众的互动中，很多人都表达了对于用低代码构建核心业务系统的担心，在我帮助信通院推进与构建低代码无代码标准的过程中，也发现各路CIO/CTO对之有大量不同的看法，他们也有大量的疑惑存在，蛮常见的一个观点就是：低代码没法做ERP。

所以今天我们来细细地聊一下这个问题，从细胞层面来剖析一个案例平台，也让更多对低代码只停留在字面意义上认知的同学们，有一个深入围观解剖低代码平台的机会。

这套低代码平台开发于2004年，与Oracle开始构建Apex是同一年，最早的用户包括深圳新一佳（年营业额200亿，100家大型卖场）、李锦记无限极、上海家得利、马来西亚最大零售商Sunshine集团等中大型企业，鉴于年代比较久远，所以当时它能做到的，现在一定能够做到，它不能够做到的，现在很多也都能做到。作为这个平台的设计者，刚好详细的与大家分享一下设计过程，一是希望对所有开发低代码平台的同学有所启发，二是希望能够给甲方的同学一些更清晰的认知。

首先是起源，为什么想做这样一个平台，在好多场合我也都分享过一个模块编译了160多次的故事，本质是因为软件的迭代要求太高，即使我们使用的是当时最高效的开发工具之一“Delphi”，但还是跟不上客户的需求迭代，纯粹的用高代码方式费时费力，简单地说，没钱挣。

我们先看一下当时的背景：2004年，零售业大发展，2001年加入WTO以后，2~3年内零售就会向外资开放，所以连锁企业个个都飞速发展，对系统的要求也越来越高，企业大发展意味着管理控制力的下降，这时候对系统的功能要求也是日新月异。

那个时候，中国还没有形成完整的管理体系，对零售管理的理念也是五花八门，主要的派系有万客隆（麦德龙）、沃尔玛、家乐福（大润发、好又多）、日系7-11、港系Circle 便利等等，随着运营高管背景的不同，都会深深的带着原来企业的烙印，这时候对软件挑战极大，换一个高管，基本所有的报表和流程都要重新迭代一次，不然，验收是不要想通过的。

2004年，当年Intel推出的CPU是奔腾四，现在几乎所有人的手机性能都远远超过了它，鉴于零售业大量的数据和运算需求，有些规模比较大的企业会购置小型机来进行运算、SAN来进行数据存储。当时新潮的软件架构是SOA(Service-Oriented Architecture 面向服务的架构)，数据库开发也有了ORM的雏形。

那么，我们需要怎么做一套适合零售企业的系统平台呢？

\\\

图源：沈欣，来自Intelligent Deployment Center（简称“IDG”）智能布署平台

首先是抽象，必须把所有的业务抽象出来，有了抽象就有了架构，因为使用的开发语言Delphi本身就是一种面向对象的语言，以前的开发中，也自己写了大量的控件进行封装，所以大约用了一周的时间，把所有零售系统功能抽象为3块：“业务对象”、“业务逻辑”、“查询”、由于零售业流程性较弱，到后期用了一种很有意思的方式加入了流程管理。

其次是目的，为什么要搞这么一个平台？只有一个口号：提升零售管理系统的开发效率，具体分为几点：“开发人员分层”、“减少低级错误”、“绝大多数客户需求调整时，无需重新编译程序“。

需要注意什么？只有两个字“性能”，因为平台一定带来性能的损失。作为核心业务系统，性能不行，那就是完全的失败了，这个问题又受限于当时的软硬件环境。

我们下面就以上这些内容一一切开、掰碎、分享一下当时的整体思考过程,同样分为三步——

1）抽象

首先是零售业务的抽象，这是当时能够想到的最极致的抽象方式了，我们逐一分析一下。

A) 业务对象，零售有大量的表单，很多软件企业以表单驱动为荣，但是表单本身就是一种经常变动的东西，我们经常发现，为了以后分析能够多一个维度，我们的表单就要增加一个字段，不同的管理风格视角大不相同，因此这是一个迭代的重灾区。业务对象内部也有层级，我们需要设计一个可以容纳比较复杂的业务对象的体系，但是实际应用中发现，大部分时候，2层已经足够。

我们在以前做数据库应用时，经常碰到一些好几张表的关联，做查询时性能很低，因此我们采用了这样的方式来设计业务对象： 首先，业务对象是一个表或者多个表的集合，其次，他们之间需要通过一个ID字段或多个字段进行关联。比如订单对象是一个订单头+一个订单体，两者之间用订单编号关联，对于连锁体系，可能还需要加上店号字段进行关联。

复杂一些的，例如商品资料对象，商品主表之外，需要加上条码表（一个商品可能有多个条码），门店表（一个商品是否在这个门店销售），分色分码表（内衣就会有尺码、色码、罩杯三个维度）、商品供应商表（商品和供应商间有一个多对的关系），商品BOM表（商品可能由不同比例的原料商品加工而成，组合商品表（商品会被临时打包成组合进行销售）。

通过业务对象，我们可以目标清晰的知道我们要对哪些数据表进行读取与操作。如何构建这个业务对象呢？我们做了一个工具，你把表的名字给他，它自动取出每一个字段，进行一个简单翻译，构建了一个SQL，你可以对这个SQL做一些小调整，然后给他设定关联字段，你需要几个表就设定几个表，最后记录为一个数据对象。

谈到数据对象，一定会有数据字典的概念，在这里，我们加入了一个数据字典，因为数据库命名比较规范，因此在业务对象构建的自动工具中，可以自动匹配数据库字段名来进行数据字典的构建，包括：字段中文名（还可以外挂多语言表，应用时一键实时切换），显示标签，显示格式、是否必填，最大值最小值，录入时的限制、新增记录时的默认值等等。

为了有更多的灵活性，还加入了情景模式，比如，同样是StoreNumber门店编号这个字段，在普通时候中文显示为”门店编号“但是在Transfer（调拨）场景下，需要显示为”调入门店“。数据字典还承载了ID和名称的子表关系，这些简单的子表数据量不大，因此就直接在数据字典里面处理了，比如主表里是国家ID，对应显示不同的国家名字放在另一个子表这种。

为什么要设计业务对象？就是为了灵活改动，同时，只要遵循一定规范，开发工作变得很简单高效，以前经常碰到的新手程序员不记得给界面上字段加上录入限制啥的这一类低级问题，都可以一次开发，多次收益。

2）业务逻辑

其次是业务逻辑，这是很有意思的一部分，当时的设计是倒推式的，先看哪些是开发重灾区，尤其是哪些今天客户要求由A改到B，明天由B改到C，后天又要求你改回A的需求。作为乙方，客户是上帝，他想咋改就咋改，但是，我必须要用最低的成本陪他折腾。

当时列了大概十个经常需要软件迭代的“灾区”，业务逻辑一直是一个重灾区，我们知道，企业随着发展，管理的视角、重点、都会变化，有时候，碰到了某些“运动“，又会临时提出新的要求。这些要求有一个特点，他们都会在某个操作节点发生。这些操作节点又分为三类，事前事中事后。

图源：沈欣提供，来自IDG智能布署平台中的业务逻辑搭建

我们会发现，事前——意味着做之前你就要告诉我，事中——意味着做的时候你要告诉我，事后——意味着做完以后我们要回顾，那么在遍布于企业管理工具的“审核“按钮后面，其实就隐藏着大量的细节。

很多时候，使用系统就是为了自动化，比如一张订货单，里面100个商品，如果是手工填入订货数量，保不齐就有这么几个商品考虑不周，导致订货数量过大或者过少。

这时候，我们需要进行一个简单的自动计算，例如，对于该次订货的某个商品的数量，需要保证他单张订单订货数量不得超过30 X日均销量，原理很容易理解，但是靠人工核对肯定不现实，这时候系统就需要自动核对，这就是隐藏在审核按钮后面的逻辑。

如果我们进一步细化，可能还需要针对“促销商品“的订货适当放宽，又比如月饼这一类的季节性商品，到中秋节前一天必须买完，那么距离中秋的日期和订货数量之间又要有一定公式来保障不会订多，再比如同样是酱油，根据商店对应的消费者的价格带不同，不同价位产品之间的库存又需要有一定控制；诸如此类，林林总总，这个审核按钮后面可能会跟着20~30个不同的业务控制点的关系，而这些控制点，又会和企业的规模、业态、品类有着关系，这意味着，即使只有20个控制点，但是不同企业有着不同的排列与组合，这也是我们一开始提到的订货功能迭代了160多次的核心原因。

那么怎么办呢？是的，我们把不同的控制点抽象成一个一个独立的业务逻辑，部署实施的时候，我们根据客户的具体情况来进行勾选即可。这就是低代码的雏形，我们将业务逻辑用低代码形式开发，可以沉淀与积累，在不同用户上就可以反复使用，而无需重新开发。

我们仍然回到表单驱动这个概念，我们发现，表单本质是一个业务对象，常见的业务操作例如新增、修改、审核，甚至打印，都是一个一个业务逻辑组，这样，我们完成了业务控制逻辑的抽象。

下一步，如果这些个审核的逻辑检查无误了，那么就要进行数据库的实际操作，也就是写入物理表，这里也可能会有很多步骤，比如，先要取出唯一单号，然后对应业务对象进行一一写表。

同样，这里也有着大量的不确定性。比如，A超市100多家，横跨不同城市与省份，一个新商品是否在不同省份的门店进行售卖，需要一个独立的“商品引入门店“动作；但是B企业只有3家标准超市门店，我们做新商品的审核时，一旦审核完成，我们就应该在门店和商品的关联表中，对这三家门店都自动增加对应关系。所以A超市不能执行自动引入门店这个操作，而B企业则有这个自动化的需求。因此，我们把这个”自动引入门店“独立为一个业务执行逻辑，可以根据不同企业的要求进行配置。

3）查询

最后是，查询。

查询其实是一个非常非常广泛被运用的功能，比如，我们进入一个模块，往往第一件事就是先进行一个查询，然后对查询出来的结果进行详细的编辑等处理。同样，我们在进行一个对门店的管理操作，往往会点一个小按钮，在弹出窗口中选择一个或多个门店，然后再进行操作，一些日常的报表。

比如门店当日销售，门店实时商品分类销售排行，都在业务系统的各个角落分布着。查询的条件也是经常会变动；比如，今天财务可能要对所有商品的税率进行核对，起因可能是国家新的税务政策，这时候，他们要么独立做一张报表进行查询，也可能会要求在商品管理模块中，增加一个对税率的查询条件，从而让各个部门的采购自己核对与调整，毕竟，很多超市有上万个品项，财务不方便自己直接去操作。

特别的，查询还面临一个性能的问题，我们经常看到的自由组合条件查询功能，在性能上有非常大的短板，毕竟当时才2004年，最新的CPU是奔腾4 处理器而已，做数据库的同学也都知道，针对任意组合的查询，由于没办法提前进行索引的优化，性能是无法保障的。

所以，我们采用了SQL构建（SQL，Structured Query Language，结构化查询语言，是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统）的方式，你只需要写一个恰当的SQL，工具会自动地构建界面，查询条件只需要进行极少量配置，就可以生成一个查询功能，大到复杂报表，小到点下下拉框显示不同结算条件。在这里，SQL就是低代码的工具。对于复杂业务逻辑的SQL，因为全部进行了拆分，反而变得非常简单。

图源：沈欣提供，来自IDG智能布署平台中搭建设置所有［业务检查］和［业务过程］中SQL用到的参数

在当年的这个平台上，无论是数据对象、业务逻辑、查询，都是用SQL工具来构建的，好处是人才好找，SQL是大学的必修课嘛，而Java、Net的人才，被互联网和游戏公司挖走得太快了……很多企业本身就有一些软件人才的储备，他们一般都精通SQL，可以直接从数据库为企业高管取数，写报表等， 对于这一类人员，大概2周左右时间，就可以非常熟练的使用这个平台。

SQL还有一个很好的优点就是性能高，毕竟是直接对数据库操作，对于一些复杂的查询，我们甚至还可以用临时表来优化，毕竟性能是我们考量的一个重要指标。

凡事有利就有弊，万一某个同学写了一个愚蠢的SQL怎么办？我们在工具中引入了一个性能审计功能，一旦打开这个开关，那么每一条通过平台执行的SQL都会被记录，包括SQL语句，执行参数，执行开始时间，执行结束时间，如果是循环执行某些小SQL，那么循环了多少次等等都会被记录，这样我们可以随时进行性能检查。

特别的，为了提高开发效率，针对常见的需求例如“查询结果计数”，“字段汇总”，“锁定查询结果表格的前几列”等等，都可以用配置方式完成，如果在SQL中针对不同结果（大于0小于0）做出配置，数据结果显示的颜色都可以自动完成，所有SQL生成的查询结果，也都可以挑出几列直接转换为各种折线图、饼状图。对于一个报表查询出来的结果，我们还可以配置成双击某一列，就会自动跳转至另一张报表，同时又自动将该条记录的信息作为跳转后报表的查询条件自动填入。

当然，鉴于OLAP和OLTP对服务器的要求不同，我们还是将特别复杂的查询都独立到业务系统之外，由BI工具来进行处理。

对于一套系统，权限是不可或缺的，对于零售业的特殊情况，还会有一些特别的权限维度，比如，两个人都是采购经理，但是一个管服装一个管家电，他们之间的数据需要隔离，也就是不能看到自己管理的品类之外的数据，这些都在平台的权限配置模块和所有查询模块中内置了，无需再次开发。

图源：沈欣提供 ，来自IDG智能布署平台中的设置功能页，设置系统中的所有权限

我们都知道，灵活的东西往往会失控，因此版本管理也是一早就注意到的功能。

软件开发是一个系统工程，我们可能会同时有三个环境：

一个是开发环境，在这里，可能同时存在几个新的功能在开发，他们可能需要对数据库结构有调整，比如增删了几个字段，这里的开发阶段的代码，和这些调整紧密关联；

第二个是测试环境，在这里，测试人员针对开发提交的代码、新数据结构等等进行部署和测试；

第三个是正式环境，这里有些规模比较大的企业还会设置多个灰度环境。

因此，我们开发的新代码，要到正式环境部署，必须有一个自动化工具，鉴于当时的低代码和功能都是采用了SQL，而且低代码平台自己（界面布局、执行逻辑、配置、数据字典等）也是以Blob方式存贮在数据库中，所以我们开发了一个导出功能，开发人员可以将自己对模块做的所有修改，都以多个SQL的方式导出，只需要将这个SQL包在新的环境执行一遍，就可以完成部署。同样的，也可以进行回滚。导出功能是可以打包进行的，如果我们给出了表单的各字段范围，还能够进行一定程度上的自动测试。

C/S架构在录入大量数据时，本地其实有个缓存，我们也利用了这个缓存做出了一些比较接地气的功能，比如录入个几百条数据，尚未提交，中途断电，当你打开电脑，会惊喜的发现数据都还在。C/S软件在录入的时候，执行效率比较稳定，因此，有很多盲录的高手，一边看着左边的打印文档，一边手指如飞的在键盘上敲编号，回车，敲数字，回车，这个也在系统中专门做了支持，如果录入的内容较多，还支持直接从Excel中拷贝进入剪贴板、直接粘贴进系统。

软件开发离不开文档，为什么后续的程序员都宁愿推翻重来而不愿意去修改代码，因为读代码太累了，有些稀奇古怪的功能背后是业务的差异化与特殊性，这时候，我们设计了一个文档工具，文档与模块紧密集成，可以记录每一次迭代的需求来自哪里，还可以记录对应的迭代版本做了些什么设计，形成了一个连续的研发体系，同时，平台可以帮助开发人员忽略掉那些常量、变量、内存回收、错误提醒的高代码，平台解耦了那些业务对象与业务逻辑以后，可以使得开发人员专注在实现业务功能的SQL代码和逻辑关系上，从而让软件的维护与迭代变得非常轻松。

在导出功能之上，还有一个逻辑导出的功能，将每一个业务逻辑以文字标题的方式按模块导出，目的是让不懂开发的业务人员可以通过这个逻辑导出的文字清楚的知道，这个审核按钮到底干了些什么。毕竟，我们问100个采购总监，99个都不会清楚系统到底干了啥。

刚才我们提到了流程，BPM工具其实一直做的不错，当然当时也有性能瓶颈的问题。在研发过程中，我们做了两个功能：

第一，业务逻辑可以和外部流程打通，比如发送短信、调用及回调OA流程等，可以方便的对接外部流程，满足标准审批的要求；

第二，在软件首页加入一个可以配置的流程图，这个流程图和权限系统集成，因为我们发现，零售从业人员更换频繁，他们碰到一个新的系统，往往会问的是俩个问题，“这个功能在哪里？我在干这个事之前需要先干（看）什么？”这个首页的流程图可以根据不同岗位的工作性质，加入常用的功能流程。

比如，先是一个超链接到FTP上的一个文档模板或者在线文档，填写上交，然后进入某个具体功能模块，填写数据，再进入某个报表，根据指引看一下报表发现问题，然后再打开某个具体功能模块做一些单据来解决刚才报表里发现的问题。在实施过程中，就可以帮助客户构建这个流程图。

随着服务客户的规模增长，性能还是一个无法摆脱的瓶颈，这时候我们发现配置的业务逻辑、业务对象，完全可以部署在不同的服务器与数据库，因此后来迭代了一个多数据库配置功能，可以指定某一个业务逻辑、业务对象、查询是在哪一台服务器上执行，也算是分布式部署的一个雏形，的确大大缓解了性能问题。

平台成熟后，我们将一直用于内部开发的工具整理了一下，加入一些常用的功能，在实施过程中我们直接给予客户培训，教会他们如何使用，后期的80%左右需求都是客户自己的几个懂SQL的同学自行迭代维护，客户省下了二开成本，我们突破了实施的运维的瓶颈，双赢。

从提出这个平台的设想到原型，大约5个开发人员加4个测试，花了半年时间，然后用了一年时间全面替换了客户的原有系统，2009~2010年，该平台进行了一次B/S迭代，从C/S架构平移到了C#.NET构建的B/S体系，2014年左右，又迭代了一个Java的版本，并可以在微软云的Azure SQL 上执行，2016年支持H5，2018年开始支持微服务架构，意味着原来执行的SQL可以全部替代为执行微服务。

同时，所有的业务逻辑业务对象也可以以微服务方式对外提供服务，十四年的时间内，系统的底层结构一直没有大的变动，只是适配了多种数据库，用不同语言重构了解释器。正是因为底层几乎没变，2019年还帮助十年前的客户马来西亚Sunshine集团进行了平滑升级，从C/S架构升级为基于云服务的B/S体系。

虽然从2017年开始我本人就没有再参与该平台的商业化迭代与开发，但是纵观系统的整个演变过程，我们认为，低代码完全可以用于复杂的大型核心应用，当低代码插上了云+微服务的双翅，犹如鲤鱼化龙，足以胜任企业内的大部分挑战。

以上就是这个十八年前的“低代码”平台从构思、到设计、研发、落地、应用的整个历程，我们可以看到，如果有对业务的深入理解，有着架构性思维体系，有面对复杂的体系进行抽象的能力，是完全可以用低代码做出一套可用、好用的核心业务系统的。

大道可以传承，也可以自悟，只要你的思维方向正确，又愿意投入时间去研究，前人能够做出来的，我们也一定能做出来。这篇文章希望能够给低代码从业人员和甲方人员一些启发，帮助大家少走一点弯路，少踩一点坑，就功莫大焉。

作者介绍：

沈欣，1996年开始从事软件开发，现为弯弓研究院联席院长/一级研究员、广东省连锁经营协会技术委员会主席、上海交通大学终身教育学院特聘讲师、中国信通院低代码/无代码推进中心技术专家、腾讯TVP智慧零售行业大使。

曾任喜茶数字化高级副总裁、百果科技首席技术市场官，百果科技首任轮值主席。

---

「品牌案例拆解」Ubras ｜ 大参林 | 蕉内 ｜ 波司登 ｜ 泡泡玛特 ｜ 幸福西饼 ｜ 茶尖尖 ｜ 每日黑巧 ｜ 汉庭 ｜ 元気森林 ｜ 泸州老窖 ｜ 蔚来 ｜ 乌苏啤酒 ｜ 五菱宏光 ｜ 喜茶 ｜ 开山白酒 ｜ 李渡酒 ｜ 肆拾玖坊 ｜ 钱大妈 ｜ 东鹏特饮 ｜ 茵曼 ｜ 观夏 ｜ 瑞幸 ｜ 屈臣氏 ｜ 孩子王 ｜ 山姆 ｜ 海伦司 ｜ 百果园 ｜ 融创文旅 ｜ 天虹 ｜ 名创优品 ｜ 惠氏臻朗 ｜ 美的｜太二 ｜ 北鼎电器 ｜郎酒 ｜朴朴超市 ｜燕之屋 ｜ 逐本 ｜帮宝适 ｜ 作业帮 | 醉鹅娘

「MarTech观察」企微 | 奇点云 | Whale帷幄 | Convertlab | 加和科技 | 有信科技 ｜ JINGdigital ｜ 爱点击 ｜ 米多 ｜ 景栗科技 ｜ 微伴助手 ｜ 有赞 ｜ 赛诺贝斯 ｜ 美云智数 ｜特赞｜兔展｜233Digital｜GrowingIO｜ 易企秀 ｜ 快决测 ｜ 筷子科技 ｜ 群脉 ｜ 迈睿 ｜ 数说故事 ｜ 云徙数盈 ｜ 观远 ｜ 艾客 ｜ 探马 ｜ 百应 ｜ 安客诚 ｜CDP | MA | 架构思维 | 低代码

本文为公众号「私域流量观察」原创，转发、合请加弯弓研究员：

更多往期精彩内容可点击下图，查看往期高赞文章合集：

点击在看 ，

分享你的思考 ↓